🏁 Script executed:

set -euo pipefail

# Locate the backup implementation and relevant tests.
fd -a 'db.rs' .
echo '---'
ast-grep outline src/db.rs --view expanded || true
echo '---'
rg -n "backup_to|VACUUM INTO|remove_file|dest.exists|same.*path|file identity|metadata" src/db.rs
echo '---'
sed -n '660,780p' src/db.rs

Repository: notedeck-dev/notecli

Length of output: 13512

🏁 Script executed:

set -euo pipefail

# Inspect the backup tests and surrounding setup to see whether same-path behavior is covered.
sed -n '1330,1518p' src/db.rs

Repository: notedeck-dev/notecli

Length of output: 6083

🏁 Script executed:

set -euo pipefail

# Check whether Database retains the source path and whether any same-file guard exists.
sed -n '95,190p' src/db.rs
echo '---'
rg -n "same.*file|canonical|metadata\\(|dev\\(|ino\\(|path:" src/db.rs

Repository: notedeck-dev/notecli

Length of output: 4278

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Map the relevant file first
ast-grep outline src/db.rs --view expanded

# Read the relevant section around the reported lines
sed -n '680,780p' src/db.rs

# Look for other backup / VACUUM INTO / strip_tokens handling
rg -n "VACUUM INTO|strip_tokens|backup|remove_file\\(|-wal|-shm|journal" src/db.rs

Repository: notedeck-dev/notecli

Length of output: 12915

🏁 Script executed:

#!/bin/bash
set -euo pipefail

sed -n '160,190p' src/db.rs
sed -n '1460,1515p' src/db.rs

# Search for any existing cleanup of SQLite sidecars around backup / temp DB handling
rg -n "suffix in \\[\"\", \"-wal\", \"-shm\"\\]|remove_file\\(.*-wal|remove_file\\(.*-shm|backup_to_overwrites_an_existing_file|backup_to_can_strip_tokens_from_the_copy" src/db.rs

Repository: notedeck-dev/notecli

Length of output: 3286

🌐 Web query:

SQLite VACUUM INTO existing destination WAL SHM sidecar files strip_tokens backup overwrite

💡 Result:

The SQLite VACUUM INTO command requires that the destination file does not exist [1][2]. If the destination file already exists, the command will fail with an error [1][2]. It cannot be used to overwrite an existing database file directly. Regarding WAL (Write-Ahead Logging) and SHM (shared-memory) sidecar files: 1. VACUUM INTO creates a new, compacted database file [1][2]. It does not create WAL or SHM files for the destination at the moment of creation [3][4]. 2. When restoring a database, existing WAL (-wal) and SHM (-shm) sidecar files associated with the destination must be manually deleted before the new database file is put in place [5]. These sidecar files are intrinsically linked to a specific database file state and are not compatible with a different or restored version of the database [5][6]. 3. If the destination file exists (and for some reason you are replacing it), you must remove the old database file along with its associated *-wal and *-shm sidecar files to prevent corruption or invalid state [5]. In summary, VACUUM INTO is a safe, non-destructive operation because it enforces the absence of the destination file [1]. If you intend to use it as part of an update or restoration process, you must manually clear the destination directory of the old database and its sidecar files before executing the command [5].

Citations:

• 1: https://sqlite.org/lang_vacuum.html
• 2: https://www2.sqlite.org/lang_vacuum.html
• 3: https://www.sqlite.org/walformat.html
• 4: https://www.sqlite.org/tempfiles.html
• 5: https://agenticdevelopercookbook.com/guidelines/implementing/data/backup-and-recovery
• 6: https://www.productionhardening.org/backup-recovery-data-integrity/

🌐 Web query:

SQLite stale WAL file replaced database file ignored salt checksum same path

💡 Result:

When you replace an SQLite database file while leaving an old Write-Ahead Log (-wal) and shared memory (-shm) file in place, SQLite will attempt to process the stale files during the next connection [1][2][3]. Because the WAL file contains metadata including "salt" values that must match the current database file header, a mismatch will occur when they do not align [4][5][6]. Here is how SQLite handles this situation: 1. Salt Mismatch: The WAL header contains two "salt" values [7][5]. When SQLite opens a database, it checks if the salt values in the -wal file match the database file [4][6]. If you have replaced the database file, the old WAL file will contain salts from the previous database [1][3]. SQLite sees this mismatch and correctly identifies the WAL as "stale" or belonging to a different database instance [3]. 2. Checksum Verification: Beyond salt checks, SQLite verifies the integrity of each "frame" (transaction) in the WAL file by computing a checksum that includes the header and frame data [8][4][6]. If the WAL is stale, or if there is a mismatch during the recovery/checkpointing process, the checksum verification will fail [8][4][6]. When a frame fails checksum validation, SQLite stops processing the WAL at that point [8][9][10]. 3. Outcome: If the WAL and SHM files do not match the new database file, the database can appear "corrupt" or "malformed," potentially leading to error messages such as "database disk image is malformed" [1][3]. SQLite does not automatically "ignore" these files in a way that preserves data; instead, it may attempt to roll back or checkpoint them, which can lead to data loss or corruption of the newly placed database file [3][9][11]. To safely replace a database file in WAL mode, you must delete the accompanying -wal and -shm files alongside the main database file [1][2][3]. The only safe way to remove these files without manual deletion is to ensure all connections are closed properly, allowing SQLite to clean them up, or by opening the database and closing it immediately via the SQLite API [11][10]. Manually replacing only the.db file while leaving stale auxiliary files in the same path is a frequent cause of database corruption [1][3].

Citations:

• 1: https://exchangetuts.com/sqlite-database-disk-image-malformed-on-iphone-sdk-1640416563800255
• 2: https://stackoverflow.com/questions/54051322/database-import-and-export-not-working-in-android-pie
• 3: https://stackoverflow.com/questions/72420883/sqlite-database-gets-overwritten-when-manually-placed-onto-device
• 4: https://github.com/endlesssoftware/sqlite3/blob/master/wal.c
• 5: https://chromium.googlesource.com/chromium/src/+/c368e30ae55600a1c3c9cb1710a54f9c55de786e/third_party/sqlite/src/src/wal.c
• 6: https://github.com/sqlite/sqlite/blob/master/src/wal.c
• 7: https://docs.rs/fsqlite-wal/latest/fsqlite_wal/checksum/struct.WalHeader.html
• 8: https://avi.im/blag/2025/sqlite-wal-checksum/
• 9: https://sqlite.org/forum/info/100daaad30d247ce9b324010721e20f2f43dd60b38ea66214cd3f568f293c8bf
• 10: https://www.sqlite.org/walformat.html
• 11: https://www2.sqlite.org/wal.html

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Map the file structure and inspect the relevant area in src/db.rs
git ls-files 'src/db.rs' 'src/*.rs' | sed -n '1,20p'
wc -l src/db.rs
sed -n '680,760p' src/db.rs

Repository: notedeck-dev/notecli

Length of output: 3457

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Show the exact function around the VACUUM INTO call and any path validation nearby
sed -n '700,750p' src/db.rs
printf '\n---\n'
rg -n "to_string_lossy|VACUUM INTO|PathBuf|canonicalize|metadata|permissions" src/db.rs

Repository: notedeck-dev/notecli

Length of output: 2905

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect permission-hardening logic and any path validation around backup callers
sed -n '120,210p' src/db.rs
printf '\n--- callers ---\n'
rg -n "backup_to\(" -S .
printf '\n--- path validation ---\n'
rg -n "to_str\(|to_string_lossy\(|is_utf8|utf-8|UTF-8|non-UTF|Path::new|OsStr|OsString" src/db.rs src/*.rs

Repository: notedeck-dev/notecli

Length of output: 4491

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Map the file and inspect the relevant area around the reported lines.
ast-grep outline src/db.rs --view expanded > /tmp/db_outline.txt
sed -n '700,780p' src/db.rs | cat -n

# Find the strip_tokens implementation and any related backup/publish logic.
rg -n "strip_tokens|VACUUM|secure_delete|Connection::open\\(dest\\)|UPDATE accounts SET token" src/db.rs

Repository: notedeck-dev/notecli

Length of output: 5002

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect DB initialization pragmas and any backup-related tests/docs.
sed -n '1,260p' src/db.rs | cat -n
printf '\n--- backup tests ---\n'
sed -n '1460,1525p' src/db.rs | cat -n
printf '\n--- search for secure_delete / temp backup handling ---\n'
rg -n "secure_delete|temp file|tempfile|rename\\(|VACUUM INTO|backup_to\\(" src

Repository: notedeck-dev/notecli

Length of output: 14773